The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / telecomm / sticpsrc.lzh / DOC / SCC.ARC / SCC.TXT < prev

Wrap

Text File | 1990-03-02 | 18.8 KB | 440 lines

The Z8530 SCC driver for the Atari ST and PC Clones By R.E. Janssen, PE1CHL. A driver has been written to support a number of Z8530 SCC chips connected to an Atari ST computer. The driver is configurable for different hardware configurations, and an example schematic supporting up to 7 SCC's (14 channels) has been included. The driver now also runs on PC Clones, although the interrupt handling capabilities of this type of computer limits the maximum speed and number of channels to a lower value than on the Atari. (depending on the speed of your machine) Each channel may be indepently programmed to support: - An asynchronous SLIP line - An asynchronous interface to a KISS TNC - Direct AX.25 (HDLC) The software has been written in such a way that a port to another environment where Z8530 SCC's are available should be relatively straightforward. Addresses of the chips are completely configurable, and most probably only the first-level interrupt handler (written in assembly language) has to be adapted to the specific configuration of the interrupt acknowledge logic in the system. The PC version supports a few special types of interface board, that use specific IO ports to control certain on-board features like MODEMs and interrupt configuration. Initialization and attachment of the channels To use the driver, 2 steps must be performed: 1. Global initialization of the driver 2. Attachment of each channel, specifying mode and options The global initialization is needed to reset all SCCs and to install a common interrupt handler. Also, the hardware addresses of the chips are defined in this step. In the second step, each channel is set up for the intended use. 1. Initialization Initialization is performed using the "attach scc init" command, using the following syntax: attach scc <number of chips> init <base address> <spacing between chips> <offset to channel A ctrl> <offset to channel B ctrl> <offset from ctrl to data> <address of INTACK latch>|0 <interrupt number> p<PCLK frequency>|r<RTxC frequency> [<special interface type> <interface parameter>] To initialize a board with 2 SCCs using my schematic, the following command would be used: attach scc 2 init fffd00 8 3 7 -2 fffd3f 3 p4915200 This specifies interrupt number 3, a normally unused interrupt in 520ST and 1040ST machines. In the newer Mega-ST this interrupt is used for the Blitter. In this case, it is possible to use the "ring indicator" input of the RS232 interface as an interrupt source. It has interrupt number 14. The INTACK latch (write, then read to get the interrupt vector) is located at 0xfffd3f. It is also possible to specify 0 for this address. In that case, INTACK is not used and the driver finds the interrupting chip by polling each RR3A register. This allows a more simple hardware design, especially for PCs. The crystal clock is specified as 4.9152 MHz. Other frequencies can be used, and this parameter should be adjusted accordingly. The clock used for baudrate generation is connected to PCLK. It would also be possible to supply a baudrate clock to RTxC, and a clock of a different frequency to PCLK (like the processor clock). This option is selected by prefixing the clock frequency with an "r" instead of a "p". The "special interface type" and "interface parameter" fields can be used to specify some special type of interface board to be used. This requires modification to the driver software. Currently, the following special types are supported on the PC: - type 1: EAGLE - type 2: PC-100 - type 4: PRIMUS - type 8: DRSI PC*Packet The PC-100 and the PRIMUS accept an interface parameter, that is used to control the on-board MODEM. It must be specified as a hexadecimal value to be sent to the output port on the board. Possible initialisation commands are: EAGLE: attach scc 1 init 2e8 8 2 0 1 0 2 p3686400 1 PC-100: attach scc 1 init 2e8 16 6 4 1 0 2 p4915200 2 22 PRIMUS: attach scc 1 init 2e8 4 2 0 1 0 2 r2457600 4 02 DRSI: attach scc 1 init 300 16 2 0 1 0 2 p4915200 8 When using an AT-type machine (with two 8259 interrupt controllers), and using the "interrupt 2" line on the BUS, specify interrupt number 9 instead of 2. This better reflects the actual configuration. The BIOS will attempt the redirection of interrupt vector #9 to #2, but it does not completely do the job. The SCC driver uses the "buffers" feature that pre-allocates a number of receiver buffers to be used by the drivers at interrupt time. Be sure to issue a "buffers <n>" command before you attach any of the SCC's channels (see below). The <n> parameter of the buffers command specifies the number of buffers to pre-allocate, this is a function of the number of channels you will attach, the baudrate of the channels, the activity on each of these channels, and the time the computer can spend without re-allocating new buffers. A good number of receiver buffers to try is 32. If you see a non-zero number in the "Space" column in the SCCSTAT output (see below) you can increase this number. It specifies the number of 128-byte buffers that are pre-allocated for the receiver buffers of all channels attached. So in this case, 4Kbytes are allocated. It is also possible to set the size of the buffers to be allocated, using the 2nd and 3rd argument of the "buffers" command. These set a minimal and maximal size of each buffer. The PC version will only allocate buffers of the maximum size (and ignores the second argument), but the Atari ST versions minimizes the thrashing of the memory freelist by allocating buffers between the minimal and maximal size, that can be carved out of the freelist without further splitting blocks of memory. Example: buffers 64 10 128 2. Attach commands When the SCC driver has been initialized, you can attach the channels. This is done using one of 3 forms of the "attach scc" command: attach scc <channel> slip <mtu> <baudrate> attach scc <channel> kiss <mtu> <baudrate> <callsign> attach scc <channel> ax25 <mtu> <baudrate> <callsign> These will be refferred to as "slip", "kiss" and "ax25" mode. The <channel> parameter specifies which half of which SCC will be programmed, as follows: channel 0: "A" side of first SCC channel 1: "B" side of first SCC channel 2: "A" side of second SCC channel 3: "B" side of second SCC etcetera. The channel number ranges from 0 to (2 * nchips) - 1, where nchips is the number of chips specified in the "attach scc init" command. SLIP mode This can be used for a link to another machine, when the channel has an RS232 interface. Example: attach scc 0 slip sl0 256 9600 This attaches the "A" side of the first SCC as interface "sl0", with an MTU of 256 and an initial baudrate of 9600. The baudrate can be changed later by: param sl0 <baudrate> Entering just "param sl0" will display the current baudrate. KISS mode KISS mode can be used to talk to a KISS TNC. It can also be used on an asynchronous link to another computer running NET. The difference with SLIP is that the interface will be AX.25 type, and can therefore be used for AX.25 connections. A callsign must be given as a parameter, this will be used for IP and NET/ROM purposes on the interface. Example: attach scc 2 kiss 430 256 4800 pe1chl-7 In the example the "A" side of the second SCC will be attached as interface "430" using an MTU of 256, a baudrate of 4800 and the callsign PE1CHL-7. The command "param 430 <paramnum> <decimal value>" can be used to set the parameters of the KISS TNC. It is not possible to display the current settings. AX.25 mode This is probably the most interesting mode to use with this interface. It allows AX.25 communication without a TNC. Only a MODEM is needed. Example: attach scc 2 ax25 430 256 1200 pe1chl-7 The parameters have the same meaning as in KISS mode. In fact, the AX.25 mode is emulating an extended KISS TNC, so the same commands can be used to set the parameters of the interface (see below). To be able to run fullduplex using an SCC in AX.25 mode, an external divider must be available, that divides the baudrate generator clock available on the TRxC pin by 32, and puts the resulting signal on the RTxC pin of the same channel of the SCC. Such a divider is not necessary for normal CSMA packet radio operation, but interrupt overhead is slightly reduced if you still install it. If you have installed the divider, prefix the baudrate with a letter "d", as in: attach scc 2 ax25 430 256 d1200 pe1chl-7 Note that when using the RTxC input as the baudrate generator clock source, you will have to feed the exact rate of the transmitter to TRxC to be able to use fullduplex. For this reason, it is better to use PCLK as the clocksource whenever possible. The DRSI PC*Packet adapter uses the Z8536 CIO on the board as a divider, so you can (and should) specify the "d" option for that board. Another option is to use external clocking, supplied by the MODEM. This is specified using the keyword "ext", as in: attach scc 2 ax25 430 256 ext pe1chl-7 The receive clock will be taken from the RTxC pin, the transmit clock from the TRxC pin. Watch the phase relationship between the clock and the data! The setting of parameters of the emulated KISS TNC is done in the same way as in the KISS mode of the SCC driver: param 430 <paramnum> <decimal value> In AX.25 mode however, it is also possible to display the current settings using "param 430". This will display a line like: speed=1200 div=y group=000 1=36 2=50 3=30 4=3 5=0 6=0 7=50 8=7 9=3 10=30. The "clocktick" unit mentioned in the descriptions below depends on the computer type. On the Atari ST, each clocktick is 10ms. On the PC Clones, a clocktick is usually 55ms, but the actual value is printed during execution of the "attach scc init". Consider that the exact time of each delay may be up to 1 clocktick time less than the specified time. It is therefore unwise to specify a value less than 2 for a delay (except when the special case 0 is selected). The parameters have the following meaning: 1: The delay (in units of clocktick) after keying of the transmitter, until the first byte is sent. This is usually called "TXDELAY" in a TNC. When 0 is specified, the driver will just wait until the CTS signal is asserted. This assumes the presence of a timer or other circuitry in the MODEM and/or transmitter, that asserts CTS when the trans- mitter is ready for data. The default value of this parameter is 360ms. 2: This is the probability that the transmitter will be keyed when the channel is found to be free. It is a value from 0 to 255, and the probability is (value+1)/256. The value should be somewhere near 20-60, and should be lowered when the channel is used more heavily. The default value is 25 (10% persistence). 3: This is the time between samples of the channel. It is expressed in units of clocktick. About 100-300 ms seems to be a good value. This parameter should never be 0. The channel will not transmit when 0 is used! The default value is 160ms. 4: The time the transmitter will remain keyed after the last byte of a packet has been transferred to the SCC. This is necessary because the CRC and a flag still have to leave the SCC before the transmitter is keyed down. The value depends on the baudrate selected. A few character times should be sufficient, e.g. 30ms at 1200 baud. The value of this parameter is in clocktick units, the default is 30ms (or at least 2 clock ticks). 5: The full-duplex mode switch. This can be one of the folowing values: 0: The interface will operate in CSMA mode (the normal half-duplex packet radio operation) 1: Fullduplex mode, i.e. the transmitter will be keyed at any time, without checking the received carrier. It will be unkeyed when there are no packets to be sent. 2: Like 1, but the transmitter will remain keyed, also when there are no packets to be sent. Flags will be sent in that case, until a timeout (parameter 10) occurs. The default value is 0, CSMA operation. 6: Control of the DTR output of the SCC. DTR will be set when this value is nonzero, it will be reset when the value is 0. After initialization DTR will be set by default. The DTR output can be used as a general-purpose output, e.g. to change between 2 transceiver frequencies or output power levels. The default value of this parameter is 1, DTR SET. 7: The initial waittime before any transmit attempt, after the frame has been queued for transmit. This is the length of the first slot in CSMA mode. In fullduplex modes it can be set to 1 for maximum performance, or to a higher value to give NET a chance to combine several packets in a single transmission. The value of this parameter is in clocktick units. It should never be set to 0. (The channel will not transmit in that case) The default value is 500ms. 8: The maximal time the transmitter will be keyed to send packets, in seconds. This can be useful on busy CSMA channels, to avoid "getting a bad reputation" when you are generating a lot of traffic. After the specified time has elapsed, no new frame will be started. Instead, the trans- mitter will be switched off for a specified time (parameter 9), and then the selected algorithm for keyup will be started again. The value 0 will disable this feature, and allow infinite transmission time. The default value is 7 seconds. 9: This is the time the transmitter will be switched off when the maximum transmission time is exceeded. This parameter is in seconds, and should never be 0. The default value is 3 seconds. 10: In CSMA mode, this parameter specifies the maximum time the transmitter will wait for the channel to become clear, expressed in units of one second. When this time has elapsed without an opportunity to transmit, the transmitter will be keyed. This is a safeguard against situations where the squelch refuses to close, or a weak carrier is present on the frequency, to prevent an indefinite pileup of frames to transmit (with a possible danger of memory overflow). Of course, the value should be set sufficiently high to prevent accidental keyups in periods of high channel load, e.g. 60 seconds. There is a compile-time option in the driver to throw away frames in this case. In fullduplex 2 mode, this parameter specifies the maximum idle time, in seconds. When no frames have been sent for this time, the transmitter will be keyed down. A value of 0 will disable this feature, i.e. the transmitter will be keyed indefinitely. The default value of this parameter is 120 seconds. Transmitter Groups It is possible to build special radio equipment to use more than one frequency on the same band, e.g. using several receivers and only one transmitter that can be switched between frequencies. Also, you can connect several radios that are active on the same band. In these cases, it is not possible, or not a good idea, to transmit on more than one frequency. The SCC driver provides a method to lock transmitters on different interfaces, using the "param <interface> group <x>" command. This will only work when you are using CSMA mode (parameter #5 = 0). The number <x> must be 0 if you want no group restrictions, and can be computed as follows to create restricted groups: <x> is the sum of some HEX numbers: 200 This transmitter will only be keyed when all other transmitters in the group are off. 100 This transmitter will only be keyed when the carrier detect of all other interfaces in the group is off. 0xx A byte that can be used to define different groups. Interfaces are in the same group, when the logical AND between their xx values is nonzero. Examples: When 2 interfaces use group=201, their transmitters will never be keyed at the same time. When 2 interfaces use group=101, the transmitters will only key when both channels are clear at the same time. When group=301, the transmitters will not be keyed at the same time, and only if both channels are clear. SCCSTAT command Once the SCC driver has been initialized, some statistic information can be shown using the sccstat command. The output of this command shows one line of information per attached channel. Example: Ch Iface Sent Rcvd Error Space Overr Rxints Txints Exints Spints 0 144 88 152 200 0 0 10013 4488 905 235 1 430 6 70 0 0 0 1915 29 0 0 The info shown is: - channel number of the attach command - name of the interface - number of frames queued for transmission - number of frames received correctly - number of receive errors (CRC, ABORT) - number of times the receiver buffer pool was found empty - number of receiver overruns and transmitter underruns - number of receiver interrupts - number of transmitter interrupts - number of receiver special condition interrupts - number of external/status interrupts It is normal that a SLIP or KISS channel shows no errors, and no special condition or external/status interrupts, while an AX25 channel has lots of these. An overrun is abnormal for all operating modes. If lots of these occur, the product of baudrate and number of interfaces is too high for the processing power of your computer. If "Space" errors occur, specify a higher number of buffers in the "buffers" command. It is, however, normal if these errors occur when you start a shell, or when you pause the output of any command using CTRL-S. This is because the processing and allocation of buffers stops in these cases, while receiver input keeps coming in under interrupt control. When you see only transmitted frames, the number of transmitter interrupts is 1, and all other counters are 0, the SCC is not generating interrupts to the computer. The single transmitter interrupt is a "simulated" interrupt that should start the transmission (but apparently doesn't).